As the “information superhighway” becomes a part of daily life, the task of managing the devices used to convey the digital traffic from one site to another becomes increasingly important. Such devices generally include relatively expensive backbone devices, and relatively inexpensive network devices referred to as access devices. Access devices include, for example, bridges, routers, hubs, and multiplexers. The user interface software used to manage an access device is referred to herein as the management interface to the access device.
Users expect the management interface to a network access device to be navigable, speedy, and safe. With respect to navigability, the interface should enable a novice user to perform routine operations. With respect to speed, the interface should permit a fluent user to meet a network problem with a timely response. With respect to safety, the software providing the management interface should enforce privilege levels and reconfirm commands which will impact service.
Over the past decade, management interfaces evolved from monitor prompts for setting registers, to forms-based dialogs, menuing systems, command languages and “natural language” parsers. A typical interface is accessed over a Telnet connection or by attaching a terminal to a console port on the device. FIG. 1 illustrates a typical command language interface for a router. Text prompts and user hints aid navigability and safety, while fluent users are permitted to issue terse, short-cut commands to enhance speed.
The internal configuration of an access device consists of thousands of bytes of state information at the hardware level. For example, the internal configuration of a typical multiprotocol concentrator consists of 32,000 to 128,000 bytes of state information. A management interface hides some of this complexity by grouping related values together into much smaller number of “configuration variables.” A management interface may further simplify the task of managing the device by supplying default profiles or templates for particular applications that will get a device running well enough to allow subsequent tuning.
To provide system managers the power required for some tasks, management software must be capable of altering every byte of state information on a device. If the device is enhanced with a new feature, the management software must be modified to access the hardware, manage a comprehensive set of configuration variables, and provide appropriate defaults. Furthermore, the interface of the management software must continue to be as navigable, fast and safe as the interface was before the enhancements were made. For example, the management software must be updated to prompt with warnings where new configuration options conflict with pre-existing ones.
A significant amount of the software effort involved in expanding the functionality of an existing access device is spent in adapting the management interface and resolving backward-compatibility, navigability and safety issues. Consequently, adding a small feature is seldom a small task. In some cases, release of features requested by customers may be delayed or blocked entirely because of the high cost of modifying and regression-testing the management interface.
As a further complication, users often automate their routine management tasks. When hardware lacks a machine-machine interface, communications scripts access the text interface and parse the responses. A new release of management software that alters the format of a date or the indent level of a menu may be rejected by users who refuse to upgrade because the cost of altering their automated data collection outweighs the benefit of the additional functionality.
To overcome some of the limitations inherent in management interfaces that rely on automated text-based interaction, a Simple Network Management Protocol (SNMP) agent may be embedded within the management software that resides on an access device. An SNMP agent is a computer program that mediates access to the configuration variables of a device through a Management Information Base (MIB). Typically, a user does not interact directly with the SNMP agent. Rather, the user interacts with management software that includes a SNMP manager. The management software containing the SNMP manager does not reside on the same machine as the SNMP agent. Rather, the SNMP manager runs on a workstation which communicates over a network with the SNMP agent according to the SNMP protocol. When SNMP management is used to configure features unique to a device produced by an enterprise, an enterprise-specific MIB is typically created and published to allow automated device management through third-party SNMP manager applications, eliminating the need for scripts.
One benefit of SNMP-based network management is that the workstation-based SNMP manager can specialize in managing the user interface while the on-board SNMP agent can specialize in checking the consistency and safety of user commands. The manager can use this division of labor to advantage, supporting multiple user interfaces of different styles, such as forms, dialogs and graphical displays.
The use of an SNMP manager may also improve the safety of the user interface. For example, where the original logic on-board the device may have warned the user of inconsistencies at the device level (e.g., when a loop-back was requested for a trunk currently in use), a workstation-based SNMP manager, having information about the surrounding network, may provide more sophisticated warnings (e.g., alerting the user that a looped-back trunk is scheduled to carry a teleconference in five minutes). Community names and MIB views may be used to enforce privilege classes for critical operations.
To control what the user of an SNMP manager can do or see, designers have created add-on applications for SNMP managers. Add-on applications are pieces of the device interface which run on a remote platform. Because add-on applications must be designed for a specific SNMP manager on a specific platform, most add-on application developers only support one or a few of the most popular SNMP managers and the most popular platforms. These add-on applications must evolve as the device evolves, track changes in the chosen SNMP Manager(s) API(s), and be ported to new network management platforms that achieve market acceptance. This often consumes disproportionate development resources. The greater the variety of management platforms in use among customers, the worse the drain on development resources.
FIG. 2 illustrates a “bilingual” access device 200 that allows access to configuration data 206 through both a text-based interface 208 and an SNMP agent 210. To access the configuration data 206 through the SNMP agent 210, a network manager interacts with the user interface provided by software containing an SNMP manager 204. The SNMP manager 204, which is typically located on a workstation (network management station 202) separate from but on the same network as access device 200, communicates with the SNMP agent 210 over the network in response to the commands of the user. When network management is performed through the SNMP agent 210, the SNMP manager 204 is mainly responsible for the navigability, network level safety and speed of the interface, while the SNMP agent 210 is mainly responsible for the device-level safety.
The text-based interface 208 provides the network manager or an operator a second access path to the configuration data 206 of the access device 200. Although the text-based interface 208 is typically less sophisticated than the user interface of the SNMP manager 204, the text-based interface 208 resides entirely on the access device and therefore does not require a network connection. Consequently, the text-based interface 208 may be the preferred access path for certain management operations, such as field service and testing.
Although SNMP-based management generally makes the task of managing network devices easier for users and eliminates the worst constraints of the text interface, the use of SNMP-based management adds to the difficulties of system designers. For example, allowing the SNMP agent access to the set of configuration variables previously managed by the text interface compromises the safety of the system. Even if the designer supplies the SNMP agent with all of the safety logic that is explicitly coded into the text interface, some additional safety logic will not be explicitly documented because such logic is simply a side-effect of the interface design. Consequently, new code must be written to ensure safety/consistency and detect race conditions between the two paths allowed to modify the configuration of a single device.
Although re-engineering the access device interface is difficult, maintaining a text-based interface co-equal with an embedded SNMP agent is even more difficult. Safety improves if the SNMP agent is the sole interface to configuration variables. With appropriate add-on software, the interface from a central SNMP manager may be made as fast as a monolithic interface, and the graphical interface of the SNMP manager is more navigable than that of a monolithic interface.
However, eliminating the text-based interface and relying exclusively on control through an SNMP manager has the disadvantage that the access device loses control over navigability and speedy access to its own configuration variables. Such control is lost because an external SNMP manager must mediate the presentation of information to the user.
Users require that access devices be easily configured and managed. As access devices grow more capable and are deployed in more applications, monolithic embedded management software exacts a high development cost, making it difficult to evolve existing products which could otherwise exploit new market opportunities. Hybrid solutions that rely on external management applications, packing SNMP agents and traditional text interfaces into one system, add complexity to the system software and put robustness at risk.